The Internet is changing many aspects of our lives, but no area is undergoing as rapid and significant a change as the way businesses operate. For businesses today, Internet technology is no longer an afterthought in forming a business strategy but has become a driving force. e-business is defined by many organizations as the transformation of key business processes through the use of Internet technologies. An e-business connects critical business systems directly to customers, employees, suppliers, and distributors via the Internet to improve time to market, access a broader base of customers and suppliers, improve efficiency, and reduce costs.
Examples of companies implementing an e-business model include retailers offering online purchasing integrated with online supply chain management or electronic financial service organizations that reduce the high cost of transactions while providing improved access to customer accounts. e-business has progressed from being a means of automating certain business functions to become an essential element of competitive business.
A framework is a reusable design expressed as a set of abstract patterns and the way their interfaces collaborate. It is a reusable design for all or part of a software system; a user interface framework only provides a design for the user interface of a system while an application framework provides a design for the entire application.
Application frameworks are becoming increasingly important for developing complex applications. An application framework describes a set of interacting components and services available to an application, the responsibilities of and the interactions between the components and services. A developer creates an application by composing and extending the components and services available in the application framework. Application frameworks typically address specific business domains, such as manufacturing or finance.
Early frameworks revolved around programming languages, such as an object-oriented (OO) design framework. Application frameworks do not have to be implemented in an object-oriented language, but they do have characteristics similar to OO design in that each component of the framework has defined interfaces and behaviour. An application framework provides a context for the software, servers, and services necessary to create, deploy, and manage complex e-business applications.
The application framework used by International Business Machines Corporation for e-business provides a model for designing e-business solutions. This model has evolved from the traditional client/server computing model and is based on an “n-tier” distributed environment where tiers of application logic and business services are constructed from components that communicate with each other across a network.
In its most basic form, the framework can be depicted as a logical three-tier computing model meaning that there is a logical, but not necessarily physical, separation of processes. With reference to FIG. 1, there is shown an example of a three-tier model (100) comprising a client tier (105), a middle tier (110; and a third tier (115).
The client tier (105) comprises clients (e.g. smartcards, digital wireless telephones, personal digital assistants (PDAs)) having logic related to sending requests to applications (e.g. through a browser or Java applet) and to presenting information and results produced by an application to the user (via a graphical user interface). The clients are sometimes referred to as “thin” clients, meaning that little or no application logic is executed on the client and therefore relatively little software is required to be installed on the client. Typically, only user interaction and input validation functions run on the client. Clients are implemented with industry-standard technologies and protocols (e.g. TCP/IP, HTTP, HTML/DHTML/XML, and Java (Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both)) that enable them to interact with the user, communicate with a middle tier and send and receive standard data formats.
The use of thin clients improves manageability, flexibility, and time to market. Advantageously, a broader range of client devices can be supported since the dependency on device capabilities are reduced.
Furthermore, user's application environments can be centrally managed and distributed to client devices of different types and in different locations to provide support for mobile users.
The middle tier (110) comprises application servers, which are single application or multi-application servers. In an e-business environment, the servers are web application servers that are optimized for Internet applications. The application servers are the platforms that provide the run-time environment for an application's business logic. The business logic is executed independently of the client type and user interface style. The separation of presentation logic from the application logic enables the creation of reusable application components that can be used from a number of different styles of user interface.
The middle tier servers incorporate several application integration technologies for communicating with applications, data, and services in other tiers. Web application transaction servers are essential in the e-business infrastructure because the number of online transactions is increasing tremendously. Customers need high-speed transaction processing, robust system reliability, backup and quick recovery of mission-critical applications. Web application servers must also provide a comprehensive integration capability with other systems. They must also connect with each other as well as the back-end third tier to enable these new business processes.
The web application servers are implemented using various Internet and Java technologies, including the HTTP server and the platform independent Enterprise Java programming environment. The latter eliminates the dependence of the business logic on the underlying hardware, operating system and networking infrastructure, thus increasing portability and decreasing development and maintenance costs. The middle tier incorporates the network infrastructure and foundation services that enable rapid development and deployment of applications in a distributed network environment. Applications (120) run as a combination of servlets, server-side scripts, and Enterprise JavaBeans (EJBs) in the web application server and its Java Virtual Machine. EJBs provide much of the business logic of an application, particularly access to database and transaction services. EJBs isolate the developer from the unique characteristics of the underlying database and transaction services, simplifying the development of platform independent business logic.
The third tier (115) comprises legacy systems that have been used for many years (hence the term “legacy”) that support new and existing internal applications, services and data; and also external applications, services and data from new and existing business partners. Connections to these services leverage value for customers, business partners and employees. External services and legacy systems are fundamental to the emergence of the web application model because they are the result of years of corporate investment in information technology. These are the mission-critical applications and data that everyone depends on daily, and they are the business assets that need to be made available to the Web in a secure, controlled way to enable companies to leverage their value for customers, employees, and suppliers in intranets and extranets. The servers in this tier provide the data storage and transactional applications used by the web application server processes.
Application elements residing in these three logical tiers are connected through a set of industry-standard protocols, services, and software connectors. The connectors (125, 126, 127) connect the new, value-add business logic in the middle tier to the vast accumulated assets in a company's existing applications and data systems in the back-end tier. The business logic running on the middle tier accepts a request (e.g. HTTP request) from the client and invokes a connector to securely communicate with the back-end tier services on the client's behalf.
An alternative model is the “data synchronization” model. With reference to the distributed system (200) of FIG. 2, an application resides on a server (215) (e.g. in storage (220)) and a replica of the same application resides on a “fat client” (e.g. a personal computer) (205) (e.g. in storage (210)). The fat client executes most or all of the processing of applications itself. When a user is offline, they can work locally on the replica data and at intervals, the user connects to the server (215), via a network (225) and the replica data is synchronized with the master data residing on the server (215). This model is often used for Personal Information Management (PIM) applications e.g. calendar, email etc and is particularly useful for mobile clients, which are only intermittently connected to the network.
Currently, many organizations would like to include data synchronization as a method to deliver e-business applications. For example, banks would like to provide customers with the ability to view and manipulate their accounts from a PDA application, with regular synchronization of the local data on the PDA with the master data on the back-end tier. However, the data synchronization model does not fit well with the e-business three-tier model. Specifically, organizations are unwilling or unable to synchronize their complex, highly protected back-end databases directly with the clients. Another complexity is that the business logic of applications running on a web application server, is driven by HTTP requests and produces HTTP responses. Synchronization protocols that are required between a client and the back-end tier are not understood by the business logic.
One possible solution is to extract a copy of the data from the back-end tier to the middle tier. The clients can then connect to the middle tier and update the data. The updated data can then be synchronized with the data stored on the back-end tier via the middle tier.
However, this solution has disadvantages. Firstly, the data that the client works on will always be out of date, especially if the data is extracted in an overnight batch. Furthermore, new application function must be developed to synchronize the updated data with the data on the back-end tier in order to maintain coherent data on the back-end tier. This in turn results in the need for distributed transaction processing, which has well-known drawbacks. For example, if a transaction coordinator “commits” a transaction (e.g. Bank A debits money from Account A and Bank B credits the money to Account B), to all resource managers that are participating in that transaction but then the network were to go down, the coherence of the state of the transaction can not be relied upon. Some of the resource managers would register the transaction as being completed, but some may not. Typically, the resource managers that require clarification on the outcome of the transaction need to contact the transaction coordinator. However, this is not possible until the network is live again and in the meantime, Accounts A and B could be locked for some time. Another disadvantage is that to scale the solution to several thin clients, the middle tier must typically comprise several web application servers. The problem of maintaining coherency therefore dramatically increases.
U.S. Pat. No. 6,023,684 discloses a three tier model, whereby at the initiation of a logical session with a client program, an application service refreshes data for a customer associated with the client program, by using data obtained from a back-end processing system through the host interface. The data is stored in local data memory associated with the application service and this data is then used by the application service for processing client requests during the logical session. The local data memory permits the processing of the client request to be decoupled from the updating of the back-end processing system.
Thus there is a need for a model that provides the benefits of the data synchronization model and the “n-tier” model, without the need for extensive change of the “n-tier” model.